More and more content is being delivered in digital form online over private and public networks, such as Intranets and the Internet. For a user, digital form allows more sophisticated content and online delivery improves timeliness and convenience. For a publisher, digital content also reduces delivery costs. Unfortunately, these worthwhile attributes are often outweighed in the minds of publishers by a corresponding disadvantage that online information delivery makes it relatively easy to obtain pristine digital content and to pirate the content at the expense and harm of the publisher.
Piracy of digital content, especially online digital content, is not yet a great problem. Most premium content that is available on the Web is of low value, and therefore casual and organized pirates do not yet see an attractive business stealing and reselling content. Increasingly, though, higher-value content is becoming available. Books and audio recordings are available now, and as bandwidths increase, video content will start to appear. With the increase in value of online digital content, the attractiveness of organized and casual theft increases.
The unusual property of content is that the publisher (or reseller) gives or sells the content to a client, but continues to restrict rights to use the content even after the content is under the sole physical control of the client. For instance, a publisher will typically retain copyright to a work so that the client cannot reproduce or publish the work without permission. A publisher could also adjust pricing according to whether the client is allowed to make a persistent copy, or is just allowed to view the content online as it is delivered. These scenarios reveal a peculiar arrangement. The user that possesses the digital bits often does not have full rights to their use; instead, the provider retains at least some of the rights. In a very real sense, the legitimate user of a computer can be an adversary of the data or content provider.
“Digital rights management” is therefore fast becoming a central requirement if online commerce is to continue its rapid growth. Content providers and the computer industry must quickly address technologies and protocols for ensuring that digital content is properly handled in accordance with the rights granted by the publisher. If measures are not taken, traditional content providers may be put out of business by widespread theft or, more likely, will refuse altogether to deliver content online.
Traditional security systems have not fully addressed this problem. There are highly secure schemes for encrypting data on networks, authenticating users, revoking certificates, and storing data securely. FIG. 1 shows a representative prior art system 20 having a content producer/provider 22 that produces original content (e.g., audio, video) and distributes the content over a network 24 to a client 26. The content producer/provider 22 has a content storage 30 to store digital data streams of original content and a distribution server 32 that transfers the content over the network 24 (e.g., Internet). The distribution server 32 includes an encoder 34 that encrypts and compresses the data prior to distribution over the network. In this manner, the data is protected in route over the public network 24.
The client 26 is equipped with a processor 40, a memory 42, and one or more media output devices 44 (e.g., monitor, display, sound card, speakers, etc.). The processor 40 runs various tools to process the data stream, such as tools to decompress the stream, decrypt the data, filter the content, and apply controls (tone, volume, etc.). An operating system 50 is stored in the memory 42 and executes on the processor 40. The operating system 50 implements a media player 52 that is capable of playing streaming media content, including both audio and video data. The media player 52 has a decoder 54 that provides the tools run by the processor 40 to decompress and decrypt the content.
Once the content is stored on the machine, there are products designed to restrict rights after purchase. For instance, a product from Liquid Audio (www.liquidaudio.com) allows a content provider to restrict content to being played only on one machine. The product secures the source material by keeping an encrypted copy of the content on disk, and keeping a decryption key safely somewhere.
While this architecture safely protects the content from the provider 22 to the client 26 and even provides some protection while stored on the client, it does not address the assurance of content security after the content has been delivered to a client's operating system. Ultimately, useful content must be assembled within the client machine for display or audio output, and again, at this point the bits are subject to theft.
FIG. 2 shows client-side components to illustrate how raw data bits may be stolen despite protections in delivery and storage of the content. Encrypted and compressed data is received from the network at a communication port 60. The data is passed to the media player 52, which implements decryption/decompression tools 54 to decrypt and decompress the content stream. The media player 52 outputs a pulse code modulated (PCM) data stream, which is essentially the raw sequence of digitized samples without compression and encryption.
The media player 52 calls to an operating system API (application program interface) layer 62 to submit the PCM data to a mixer 64 (or other processing component). The mixer may be implemented, for example, using ACM (audio compression manager) or DirectX technology from Microsoft Corporation. The mixer 64 processes the PCM data with other sources to produce a desired output. At this point, the processed data is passed to a driver 66 (software and/or hardware) which outputs the data to the media output device(s) 44, such as a sound card and speaker, or a display.
With this traditional architecture, the data is left unprotected throughout the operating system software and hardware of the client device. Regardless of the upstream encryption and compression, the data is eventually passed to the lower level software and hardware components in a clear (unencrypted) form, which can be stolen. For instance, an attacker might introduce a fake driver 72 to receive the data from the mixer 64 and store the raw data on a storage medium 74 for illicit use that is not contemplated by the content provider (e.g., redistribution, multiple plays, etc.). Suppose, for example, that the media player is implemented using DirectX API layers. DirectX is an open standard that allows software applications to read sound and video data. A software package (e.g., “Total Recorder” software package) can install itself as if it were a sound card driver (i.e., fake driver 72) and all audio or video that flows into this virtual sound driver can be captured into a standard sound file (e.g. in “.wav” format).
Accordingly, there is a need for an architecture that protects bits after they have been given to the operating system. It is also desirable that the architecture integrate with an existing multimedia processing system called “DirectX” from Microsoft Corporation, which runs atop Windows brand operating systems. The DirectX architecture defines how to control and process streams of multimedia data using modular components called filters. Examples of filters include compressors, decompressors, renderers, mixers, parsers, splitters, and tuners for both audio and video data types. The filters have input or output pins, or both, and are connected to each other in a configuration called a filter graph. Applications use an object called the filter graph manager to assemble the filter graph and move data through it. The filter graph manager provides a set of Component Object Model (COM) interfaces so that applications can access the filter graph. Applications can directly call the filter graph manager interfaces to control the media stream or retrieve filter events, or they can use the media player control to play back media files. The reader is directed to the Microsoft web site Microsoft.com, and the file path for “directx” for more background information on DirectX, filter graphs, and individual filters.
One of the main attractions to the DirectX architecture is that it is modular and extensible. Unfortunately, these same advantageous attributes may be manipulated for improper use. For instance, a thief may insert a “T” into the filter graph to siphon compressed or uncompressed data to disk.
One possible approach is to secure the filter graph and the device drivers using only certified components. The drawback with this approach is that it introduces the burden of obtaining certificates for components and authenticating them during use.
Another approach is to keep the data encrypted until it reaches the driver layer 66. This approach has a drawback in that it may lead to poor quality output because some processing results from the filters do not transfer cleanly through the decryption algorithm when the encrypted data is subsequently decrypted, oftentimes rendering the data unrecoverable. Consider, for example, an encrypted MPEG stream. It will lose the MPEG transport layer framing and the filter graph will be unable to handle it. Another example is PCM audio. If the encrypted audio is mixed with another signal (e.g., a “ding” from a mail program), decryption is impossible. As a final example, a volume control that multiplies an encrypted audio bit stream by a constant renders an encrypted stream unrecoverable.
Thus, there is a need for an architecture that protects data while in the operating system and hardware components of the computer and integrates with the DirectX architecture, without deterioration of the signal quality when played.